home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9298 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  9.1 KB

  1. Path: cerberus.fon.sprintcorp.com!news
  2. From: Eric Williams <Eric.R.Williams@ksopk.sprint.com>
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: Thu, 29 Feb 1996 14:59:30 -0600
  6. Organization: Sprint
  7. Message-ID: <313613B2.136E@ksopk.sprint.com>
  8. References: <3134D499.653E@ix.netcom.com>
  9. NNTP-Posting-Host: shire.fon.sprintcorp.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0b6a (X11; I; HP-UX A.09.05 9000/712)
  14. CC: williams
  15.  
  16. philstep@ix.netcom.com wrote:
  17. > I have resisted learning C++  for long time because  I've considered it
  18. > too complex. Sure, operator overloading is powerful, but doesn't it
  19. > allow  a  programmer to essentially createhis *own* language that
  20. > only *he* understands?  Sure, pointers are powerful,  but they seem to
  21. > cause more problems than they solve (particularly  in a competitive
  22. > software market, where it is important  to get a product to market FAST,
  23. >  never mind thoroughly debugging it.)  I'm happy that Java strips out
  24. > some of the more complex aspectsof C++.  But, will people dump C++ for
  25. > Java?  I sure  hope so. I  can hang my hat on Java.
  26.  
  27.  
  28. Java is significantly less complex than C++, from a programmer
  29. perspective.  Here are my thoughts on some of the issues you
  30. raised:
  31.  
  32. 1. Operator overloading
  33.  
  34. Many people think of this as a "powerful" feature.  In my experience,
  35. operator overloading is, as you say, a way for a programmer to create
  36. their own language.  In effect, operator overloading introduces a
  37. form of "shorthand notation" into C++.
  38.  
  39. Is this powerful?  It is intended to be *conceptually* powerful,
  40. allowing
  41. users to easily understand operations like "Complex + Complex".
  42. Operator
  43. overloading does not add significant functionality to a language,
  44. however.
  45. Overloaded operators are just methods... you can implement identical
  46. functionality using "regular" methods.
  47.  
  48. I am glad that Java does not have this feature.  Java already
  49. has enough complexity; the more the language avoids unnecessarity
  50. complexity, the more room there is for the *necessary* complexity.
  51.  
  52.  
  53. 2. Pointers
  54.  
  55. Pointers in C++ are a legacy of C.  They allow you to do a great many
  56. things..... including shooting yourself in the foot in an infinite
  57. variety of ways.
  58.  
  59. Let's face it.  Most modern programming languages have enough
  60. expressivity
  61. to allow you to write the programs you want to write.  It all comes down
  62. to how difficult the task is in any particular language.  With C/C++,
  63. you
  64. must spend a great amount of time and energy worrying about pointers:
  65. null pointers, un-initialized pointers, pointer arithmetic, pointers to
  66. stack memory, pointers to heap memory, pointers to uninitialized memory,
  67. pointers to de-allocated memory, pointer casting, pointers and data type
  68. sizes, etc..  You spend a lot of time writing pointer-safety checks and 
  69. using tools (ObjectCenter, Purify, BoundsChecker, etc.) to verify that
  70. your code is not abusing pointers.
  71.  
  72. Part of Java's strength lies in the fact that that the programmer does
  73. not have to worry about physical pointers.  Pointers (references) in
  74. Java have no machine dependencies.  You don't even have to worry
  75. about crashing the entire process when de-referencing a null pointer
  76. (you just handle the NullPointerException).  A Java pointer/reference
  77. is either null, or it refers to an object that is guaranteed to be
  78. type-compatible with the reference.
  79.  
  80. On the flip side, part of what make applications easy to build in any
  81. particular programming language are the tools and libraries available 
  82. in that language.  In this respect, Java lags way behind C/C++.  The
  83. tools are only now starting to become available.  If you adopt Java
  84. now, you might be faced with building many of the tools/frameworks
  85. that exist as off-the-shelf packages for C/C++.  In many situations,
  86. these off-the-shelf packages will mean less overall development time
  87. in C/C++ vs. Java.
  88.  
  89.  
  90. 3. Memory Management
  91.  
  92. You didn't touch on the issue of memory management, but I feel that
  93. this is one of the strongest selling points of Java.  C/C++ programmers
  94. spend so much time chasing memory leaks.... and designing and
  95. re-designing their code to perform proper memory management.
  96.  
  97. Explicit memory management may be efficient for some applications.  It
  98. may also be highly practical in some realms (like real-time systems).  
  99.  
  100. But for the majority of applications, explicit memory management is a
  101. major headache.  These applications become *much* easier to construct
  102. once the programmer is freed from the burden of explicitly managing
  103. memory.
  104.  
  105.  
  106. 4. Threads and Monitors
  107.  
  108. C and C++ have very little to say about thread management, and less
  109. to say about synchronization.  These are usually implemented as
  110. external libraries..... with different APIs on different platforms.
  111. Using threads and semaphores makes C/C++ applications much less
  112. portable and much more difficult to debug.
  113.  
  114. Java, however, has a built-in threading and synchronization model.
  115. The Java VM deals with the platform dependencies.  I recently wrote
  116. a multi-threaded request queue in 1/2 hour in Java, just about as
  117. fast as I could type it.  The code is portable to all platforms the
  118. JVM runs on.  If I were to try this in C++, it would probably have
  119. taken me 1 week to write the code, plus another week to port it to
  120. other platforms.
  121.  
  122. I can't wait to see performance benchmarks for JIT compiled Java,
  123. using native threads, running on a multi-processor machine.  You would
  124. probably be able to beat the performance numbers with well written
  125. C/C++, but then again, you could probably beat well written C/C++
  126. using well written assembly language.  :)
  127.  
  128.  
  129.  
  130. 5. What about Smalltalk?
  131.  
  132. Everything I've mentioned so far (with the exception of *real*
  133. threading)
  134. can also be said of Smalltalk.
  135.  
  136. In fact, Smalltalk is *way* ahead of Java w.r.t. many issues:  JIT
  137. compilation, advanced graphical framework, development environments,
  138. toolkit availability, database connectivity, stability, market share,
  139. etc..
  140.  
  141. Java does have the jump on Smalltalk in other areas:
  142.  
  143.   * There is no unity in the Smalltalk market.  There are
  144. incompatibilites
  145.     between the major Smalltalk environments (VisualWorks, VisualAge,
  146.     Enfin, etc.).  Java has unity, for now.  And Sun is intending to
  147.     keep it that way, by allowing the Java name to be used only for
  148.     "compliant" implementations.
  149.  
  150.   * Smalltalk still has a polling model for graphical interaction.  From
  151.     what I hear, there is work going on to replace this with an event-
  152.     driven model, but it's not here today.  The Java AWT is already
  153.     event-driven.
  154.  
  155.   * Smalltalk does not use native threads.  Sun has already delivered
  156.     native threading for Java/Win32.  I hear that sun is working on this
  157.     for Solaris.  It would be logical to assume that Java will use
  158.     native threading whenever possible.
  159.  
  160.   * Smalltalk does not yet have the byte-code security necessary for
  161.     Internet executable content.  Java was [re]designed for this.
  162.  
  163.   * Java has been embedded in the Netscape browser.  As of today, you
  164.     can write Applets that will execute over the Web on a Netscape
  165.     browser.  Smalltalk can not make this claim.
  166.  
  167.  
  168. For now, Smalltalk is probably a better choice for application 
  169. development.  For Internet Applet development, however, the choice
  170. is clear.
  171.  
  172.  
  173. The question "Will Java Kill C++?" can really be expanded to:
  174. "What effect will Java have on C++ and Smalltalk?"
  175.  
  176. I don't know the complete answer.  Java solves a number of problems
  177. that programmers face.  If you were to attempt to build a major 
  178. application in Java today, however, your programmers would face
  179. difficulties that have already been solved in C++ and Smalltalk.
  180.  
  181. To further complicate the question, will Java expand from its
  182. niche market (Internet executable content) to become a full-fledged
  183. application development language?  Will people take it seriously
  184. as such?
  185.  
  186. Java has promise.  But it will take time and energy to convert on
  187. this promise.  The existing tools have to stabilize.  The graphical
  188. library (AWT) must improve.  And many, many vendors need to
  189. introduce commercial-quality software development tools/libraries.
  190. In addition, the JDBC specification must deliver secure access
  191. to corporate data.
  192.  
  193. Java also has momentum.  And along with that, media attention.  Yes,
  194. there is a lot of hype, but that means that people are getting
  195. excited about the language.  Nothing encourages investment in a
  196. technology like *continued* media attention.
  197.  
  198.  
  199. I haven't been around the computer industry long enough to predict
  200. with certainty what will happen, but I doubt that Java will completely
  201. uproot any existing language.  That's just too expensive.  Today's hot
  202. technology will become tomorrow's legacy system (supporting an entire
  203. arm of the consulting industry).  Some development will shift gradually
  204. to Java, as the language stabilizes and offers more development tools.
  205. Will it be C++ or Smalltalk that loses more to Java?  Intuitively, I
  206. would say that C++ will be the first to lose programmers to Java.  Java
  207. is syntactically similar to C++, so C++ programmers easily learn Java.
  208. But Smalltalk will also lose programmers to Java if the major Smalltalk
  209. players don't address the "Internet executable content" issue.
  210.  
  211. It will be an interesting next couple of years, at any rate.
  212.  
  213.  
  214. -eric
  215.